Date: Tue, 20 Apr 93 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #107
To: packet-radio


Packet-Radio Digest         Tue, 20 Apr 93       Volume 93 : Issue  107

Today's Topics:
                                (none)
                          Info on PackeTerm
                       Internet port on packet
method for improving packet thruput in noisy channels (well, maybe) (4 msgs)
    PTM522WW.ZIP - Danish Packet Terminal & Mailbox - Multi-ling.
       rec.radio.amateur reorg: current/evolving proposal 4/17
                    Single chip receiver for FSK?
             Special Event Station "Memphis Belle" "W4BS"
               WANTED:  TCM3105 chips, small quantities

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 19 Apr 93 17:40:01 GMT
From: news-mail-gateway@ucsd.edu
Subject: (none)
To: packet-radio@ucsd.edu

I am working on a problem of scheduling classroom, and I will like to know if
you have some software, papers or articles about it. If you have something
relate it,  please let me know.

		thanks

		Lorenza Illanes

------------------------------

Date: 19 Apr 93 13:00:00 MDT
From: usc!sdd.hp.com!portal!lhaven.UUmh.Ab.Ca!Lawrence_Chen@network.UCSD.EDU
Subject: Info on PackeTerm
To: packet-radio@ucsd.edu

Hello Amiga Packet people.

I'm looking to break into Packet myself....and I was reading through CQ,
and saw an ad for PackeTerm.

Has anybody out there used this program?  If so, can they post or send me a
quick review of the product?

I'd also like pointers to other Packet related products for the Amiga.

aTdHvAaNnKcSe


-- Via DLG Pro v0.995

 "Just a Crazy Engineer with an Amiga and an HP48sx"    - The Dreamer
 Email: dreamer@lhaven.uumh.ab.ca or "Lawrence Chen" @ 1:134/3002
 PHONE: +1 403 526 6019        FAX: +1 403 529 5102        CIS: 74200,2431
 Lunatic Haven BBS (1:134/3002):      +1 403 526 6957 (14,400 HST/v.32bis)
 Lunatic Haven BBS (UUCP):            +1 403 526 5035 (Telebit Worldblazer)
 Praxis Society K12 BBS (1:134/3003): +1 403 529 1610 (Telebit T2500SA)

------------------------------

Date: Mon, 19 Apr 1993 22:40:45 GMT
From: agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!ux4.cso.uiuc.edu!apeters2@ames.arpa
Subject: Internet port on packet
To: packet-radio@ucsd.edu

I think the subject line says it all.  Is there a 
way to get into internet or any other worldwide or
nation-wide "land-line type" net?

Avram
n9oni
apeters2@ux4.cso.uiuc.edu

------------------------------

Date: Mon, 19 Apr 1993 16:48:49 GMT
From: kgw2!NewsWatcher!user@uunet.uu.net
Subject: method for improving packet thruput in noisy channels (well, maybe)
To: packet-radio@ucsd.edu

In article <1993Apr19.033253.18601@cbfsb.cb.att.com>,
wa2ise@cbnewsb.cb.att.com (robert.f.casey) wrote:
> 
> 
> Better packet reception
> 
> How about this method for improving packet reception (probably has been
> done, but here goes anyway).  Sometimes, when noise causes a few errors
> in a received packet, the CRC rejects the packet and tells the transmitting
> station to resend it.  If the noise persists, you are in for a lot of
> retries, and thruput is bad.  Let's say, for example, that the received
> packets have about 5 errors.  
> 
> Suppose the receiving TNC stores the bad packet.  and if the next try is
> also bad, store it.  And if the third try is also bad, you could compare
> all three, byte by byte, and look for where they differ.  
...

If the error rate is relatively low, you probably don't need to get the
third try.  Just create a third packet, trying data from both of the faulty
packets until the CRC checks out.  


Dave Steele
Xetron Corp.
40 W. Crescentville Road
Cincinnati, Ohio 45246

------------------------------

Date: Mon, 19 Apr 1993 15:53:40 GMT
From: usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.UCSD.EDU
Subject: method for improving packet thruput in noisy channels (well, maybe)
To: packet-radio@ucsd.edu

In article <1993Apr19.033253.18601@cbfsb.cb.att.com> wa2ise@cbnewsb.cb.att.com (robert.f.casey) writes:
>
>Better packet reception
>
>Suppose the receiving TNC stores the bad packet.  and if the next try is
>also bad, store it.  And if the third try is also bad, you could compare
>all three, byte by byte, and look for where they differ.  Errors should
[delete]
>Don't know if this is usually done ("Don't you know that this is called
>'digital blah blah ba blah', anyone who had 'Packet 101 knows that!"), or maybe
>the extra s/n margin this would buy is too small to be worth the trouble?
>It's just some more code in the TNC's EPROM, and a little more use of 
>scratchpad RAM, which room probably exists already without increasing
>parts count or cost.  Just an increase of the time for someone to write it.
>(No, I don't have the programming skills to try this myself, unfortunately).

This *is* a familiar approach. It fails when the packets aren't framed
correctly, which unfortunately is very common on the noisey channel. 
This will shift the relative byte positions one or more bits left or 
right. This makes the comparison impossible unless you have the horsepower 
to do shift and compares across the length of the packets. This is one of 
those n^n computational problems. It *is* simple in that it will work with 
ordinary packet stations, but it doesn't work often enough to be robust.

A much stronger system that uses a different version of FEC is 
computationally possible.  Bit errors tend to come in batches 
due to the nature of the channel, so if you arrange the packet
so that adjacent bits aren't transmitted in sequence you can
"smear" the error out in such a way that simple error correcting
codes can reconstruct it. To do this you prepare the packet by
reading it into the rows of a matrix, attaching a simple Reed
Solomon FEC to the end of each row. You then read the data out
for transmission by columns, attaching a RS FEC to the end of
each column. On receive you read the data back into a matrix
by columns, do the FEC calculations, repair damaged bits, and
read the reconstructed packet out by rows. Though this sounds
more complex, the computational requirements are less, log(n),
than the misframed case for the other method. It does require both 
stations to cooperate in using the method. This is the method 
used in digital video recorders to deal with "dropouts" in the 
magnetic media, similar to RF noise bursts. It's amazingly robust.
The FEC adds some overhead, but since resends become rare, it's
thruput is better.

In pure gaussian noise, a soft decision bit slicer can enhance
operations even more, but it fails to be useful in the presense 
of strong non-gaussian interference.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: Mon, 19 Apr 93 19:14:12 GMT
From: gumby!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!adec23!mark@yale.arpa
Subject: method for improving packet thruput in noisy channels (well, maybe)
To: packet-radio@ucsd.edu

wa2ise@cbnewsb.cb.att.com (robert.f.casey) writes:

>Better packet reception
> . . .
>Suppose the receiving TNC stores the bad packet.  and if the next try is
>also bad, store it.

FEC of a form. I would even go simpler than that, I would take *any*
differences and try them all (why look just for pairs that match). The only
(slight) problem is that you are increasing the chances of receiving a packet
full of errors as if it was correct (Data wrong, CRC sez not). There are
also cases of bit slipping too (loose a bit) that could get your mind
wandering.

I did something like this with passall-on and let the confuser reconstruct
traffic on the channel from the ascii streams. I did *not* see any improvement
of copy (and I took a performance hit on the box as it was slow already), but
that is probably due to the fact I was monitoring rather than being an active
participant (and the fact I did not have access to the CRC) ...

Now, the `technical' problem. The TNC has NO idea what the CRC is, since
the Synchronous UART strips that off before presenting it to the CPU. It is
possible to tell the UART to not do the CRC stuff, but that is a big change
to the software operation of the TNC (Any Z-80 based TNC). I believe the
KAM's processor has good access to the CRC, but with their support, and
our lack of source code ...

Ok, who is going to add this to their KISS firmware first?

Ciao, 73 de VE6MGS/Mark -sk-

------------------------------

Date: Mon, 19 Apr 93 23:00:57 GMT
From: usc!howland.reston.ans.net!usenet.ins.cwru.edu!agate!news.ucdavis.edu!csus.edu!netcom.com!netcomsv!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com!dana@network.UCSD.EDU
Subject: method for improving packet thruput in noisy channels (well, maybe)
To: packet-radio@ucsd.edu

In article <daves-190493124744@129.228.20.182> daves@xetron.com (Dave Steele) writes:
>In article <1993Apr19.033253.18601@cbfsb.cb.att.com>,
>wa2ise@cbnewsb.cb.att.com (robert.f.casey) wrote:
>> 
>> 
>> Better packet reception
>> 
>> How about this method for improving packet reception (probably has been
>> done, but here goes anyway).  Sometimes, when noise causes a few errors
>> in a received packet, the CRC rejects the packet and tells the transmitting
>> station to resend it.  If the noise persists, you are in for a lot of
>> retries, and thruput is bad.  Let's say, for example, that the received
>> packets have about 5 errors.  
>> 
>> Suppose the receiving TNC stores the bad packet.  and if the next try is
>> also bad, store it.  And if the third try is also bad, you could compare
>> all three, byte by byte, and look for where they differ.  
>...
>
>If the error rate is relatively low, you probably don't need to get the
>third try.  Just create a third packet, trying data from both of the faulty
>packets until the CRC checks out.  
>


It really depends how strong the CRC is.  You could easily get an erroneous
packet which checks out against the CRC.  Furthermore, the kinds of errors
you get may cause the receiver to lose sync with the incoming data and
not receive anything at all until it sees another flag.  You can't just
store a fragmented piece of a packet without a lot of special effort.

FEC packet would work more easily with less magic; you just program your
TNC to send every packet twice.  Heck, rather than using a long TXD you
could a very short TXD and send the packet twice.  The TX Delay time is
simply wasted time to let someone's receiver warm up.  Sending the
packet twice would give slow receivers a chance to warm up and give
the quick receivers (i.e. people using DCD State Machines) two chances
at reading a noisy a packet....

Dana

-- 
 * Dana H. Myers KK6JQ 		| Views expressed here are	*
 * (310) 337-5136 		| mine and do not necessarily	*
 * dana@locus.com  DoD #466 	| reflect those of my employer	*
 * This Extra supports the abolition of the 13 and 20 WPM tests *

------------------------------

Date: Tue, 20 Apr 1993 07:02:14 GMT
From: tacom-emh1.army.mil!msdos-ann-request@uunet.uu.net
Subject: PTM522WW.ZIP - Danish Packet Terminal & Mailbox - Multi-ling.
To: packet-radio@ucsd.edu

I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu:

pd1:<msdos.packet>
PTM522WW.ZIP    Danish Packet Terminal & Mailbox - Multi-ling.

PTM Packet Terminal V 5.22 is a Danish Packet Terminal and Mailbox.
At the moment PTM is able to talk Danish, Swedish, Norwegian, English,
Italian, Spanish, French, German and Russian.  It supports several
modems: TNC2c, PK-88, PK-232, KAM 2.85, KAM 5.02, and TNC241.  The
mailbox will default to english, but give the user an option to change
the language to be used.

The PTM Mailbox does support file uploads and downloads, and many other
features.

The program can be used with no limitations, but the author asks users
to register - Read the following section of the documentation:

- -
        If you do not register your copy at once the only consequence
        is that PTM will flash a reminder for 30 sec's before starting
        up.  There are no other limitations in the program.
- -

Per Holm - ph@fi.aau.dk
- -
 Internet: ph@fi.aau.dk
 X.400: C=dk; ADMD=dk400; PRMD=minerva; O=aau; OU=fi; S=ph
 FidoNet: Per_Holm@2:230/22
 HamNet: Per_Holm@12:210/107
 EEggNet: Per_Holm@97:9451/4

------------------------------

Date: Mon, 19 Apr 93 15:21:53 GMT
From: usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!adec23!mark@network.UCSD.EDU
Subject: rec.radio.amateur reorg: current/evolving proposal 4/17
To: packet-radio@ucsd.edu

ikluft@uts.amdahl.com (Ian Kluft) writes:

>rec.radio.amateur.rdf                   radio direction finding: recreational
>					hunts and searches for interference
>rec.radio.amateur.antenna		discussion of amateur radio antennas
There is the act of rdfing and then there is the equipment. equipment will
grey area into .antenna or .equipment AND .rdf. (Not a
disagreement with the proposal, just half hearted support :-)

>rec.radio.amateur.operating             Operating procedures and questions: DX,
>                                        CW, contests, propagation, repeaters
>  alternatives proposed: r.r.a.dx and r.r.a.repeaters
The .repeater group will degenerate (poor word!) I think into not much
different than .policy discussions. I'd stick with .operating with a good
short FAQ saying that .dx discussions are greatly welcomed (as the name
could add confusion for the .dxers, but much of what they will say WILL
be salient to operating procedures).

>Issues currently under discussion
>---------------------------------
>The following issues and notes relate to the discussions listed above:
>* a place for beginners to ask their typically-unfocused questions
>  suggestions: r.r.a.beginner (markz/jbloom/emd)
>  concerns: r.r.a.instruction allows enough room for license upgrades as well
>    and r.r.a.beginner will have the same questions repeatedly (pschleck/
>    ikluft/jgt10/kevin)
If I was a newbie on both USENET and Amateur Radio, I'd go to .misc first.
I am not sure we can focus beginners into any specific group, and once they
are less green under the collar, participation drops off quickly.

>  results so far: only the name is in dispute, beginner or instruction will
>    be on the CFV.  r.r.a.instruction is slightly ahead - can everyone live
>    with it?
.instruction since it encompasses more.

>  results so far: only the definition is in dispute, dx or operating of some
>    sort will be on the CFV.  r.r.a.dx and r.r.a.operating seem to ruffle the
>    fewest feathers - can everyone live with them?
I'd be saddened to see the .dx crowd not imparting their operating procedure
know how ;-) , but yes, this proposal (I don't support the split of this group,
but this split sounds the best).

>  To break the deadlock: can you live with r.r.a.construction?  If not,
>    should we roll up products/construction/technical and call them
>    r.r.a.equipment?  (That seems to fit the theme everyone is arguing over.)
I rest (what, you think you have worn me out! :-) and support .equipment
as the meta for products/construction/technical/tech/homebrew/.shack (<---hmmm)

What do you mean the nntp link is down <shaking feverishly> -- 73 de VE6MGS/Mark

------------------------------

Date: 19 Apr 93 11:40:49 GMT
From: pipex!uknet!acorn!agodwin@uunet.uu.net
Subject: Single chip receiver for FSK?
To: packet-radio@ucsd.edu

In article <C5L0xM.E25@law7.DaytonOH.NCR.COM> jra@law7.DaytonOH.NCR.COM (John Ackermann x 2966) writes:

>My goal is to come up with an inexpensive design for a receiver "back
>end" with IF input on one end and an FSK demondulator on the other.  I'm
>particularly interested in ways to use a higher IF than 10.7 -- do any
>current chips work up to, say 150MHz with internal downconversion so a
>normal IF filter can be used?
>

GEC/Plessey specify a series of FM demodulators (SL1454 etc) for use in
satellite TV receivers : 150 or 600MHz in, 10MHz of baseband video out.
I think there's also a related data slicer / clock recovery circuit intended
for use in DMAC decoders, though that isn't used in the most common 
implementation - it may not be in volume production.

The most easily available components probably vary with local satellite
standards, and I think the european systems vary rather widely from those
in the US - so it may be worth investigating locally-available receiver
designs to find out what's in common use.

-adrian


-- 
Adrian Godwin : agodwin@acorn.co.uk : adrian@fangorn.demon.co.uk : g7hwn@gb7khw
ObDisclaimer  : I believe this rubbish .. don't imagine that anyone else does.

------------------------------

Date: 19 Apr 93 17:42:46 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!caen!destroyer!cs.ubc.ca!alberta!ugc!nebulus!ve6mgs!rec-radio-info@network.UCSD.EDU
Subject: Special Event Station "Memphis Belle" "W4BS"
To: packet-radio@ucsd.edu

The Delta Amateur Radio Club of Memphis, TN., will be hosting "W4BS"
Special Event station to commemorate the 50th anniversary of the 25th and
final mission flown by the world famous B-17 "MEMPHIS BELLE".  The 25th
Mission was flown on May 17, 1943.

This special event will be from 1300Z, May 16th until 0100Z, May 17th.  The
transceivers will be set up in the pavilion next to the "BELLE" on Mud
Island in Memphis, Tennessee.  We will operate the following stations:

               2 Meters - 146.550 Mhz
              10 Meters -  28.455 Mhz
              15 Meters -  21.320 Mhz
              20 Meters -  14.305 Mhz
              Packett   - 145.01 Mhz and on the Internet Converse (CH. 25)

For an especially nice certificate send QSL with contact number and SASE
to:

              MEMPHIS BELLE
              c/o DARC
              P.O. Box 16343
              Memphis, TN  38186-0343
              USA

For more information, please contact:

              David Moore at:
              KD4CAC @ W4BS.#WESTN.TN.USA.NA
              kd4cac @ gate.n9gsa.ampr.org

___  ___  _____  ___ ___ Suresh Kagoo  EE Dept , Memphis State University
|  \/  | / ____\ | | | | Engineering 211   | Domain: KAGOOS@MEMSTVX1.MEMST.EDU
| \  / | \____ \ | |_| | Memphis, TN  38152| AMPR  : n9gsa@gate.n9gsa.ampr.org
|_|\/|_| \_____/ \_____/ Ph: (901) 678-3867| AX.25 : N9GSA@W4BS.#WESTN.TN.USA

------------------------------

Date: 20 Apr 93 00:44:18 GMT
From: pa.dec.com!e2big.mko.dec.com!dbased.nuo.dec.com!news.crl.dec.com!payne@decwrl.dec.com
Subject: WANTED:  TCM3105 chips, small quantities
To: packet-radio@ucsd.edu

Does anyone know if a source for the TCM3105 modem chips (as used in the
Baycom and my PMP modems)?  Ideally, something that is geared toward 
hobbyists:  small quantity, mail order, etc.

For years, we've been buying them from a distributor (Marshall) by the
hundreds for PMP kits.  But orders have dropped to the point where we can
no longer afford to offer this service.  And all of the distributors I've
checked have some crazy minimum order ($100, or so).

I'd like to find a source for those still interested in building PMP kits.
Any suggestions?

-- 
Andrew C. Payne
DEC Cambridge Research Lab

------------------------------

End of Packet-Radio Digest V93 #107
******************************
